System and method for machine to machine subscriber information and retrieval protection

ABSTRACT

Systems and methods utilize a machine type communication interworking function and mapping function to manage and route requests from a variety of devices in data networks.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to and is a continuation of U.S.patent application Ser. No. 16/054,527, filed Aug. 3, 2018, which is acontinuation of U.S. patent application Ser. No. 15/452,270, filed Mar.7, 2017, now U.S. Pat. No. 10,075,827, which issued Sep. 11, 2018, thecontents of which are incorporated herein by reference in its entirety.

TECHNICAL FIELD

This disclosure relates generally to network management and, morespecifically, to facilitate increased use of machine to machinecommunication.

BACKGROUND

An increasing number of Internet of Things (IoT) devices, and othersmart devices, include independent network connectivity. Suchconnectivity facilitates enhanced functionality, remote control, andother improvements. To provide such connectivity, however, mobileservice providers need to support an increasing number of IoT services,often across multiple industry segments, such as automotive, utilitymeters, vending machines, and healthcare. Managing the associatedtraffic volume and maintaining the identity of originators and targetsof network transmissions has become more challenging.

Accordingly, what is needed are new techniques for traffic management toaid in providing service for increased numbers of connected devices andassociated traffic.

SUMMARY

In embodiments, an apparatus comprises a having a processor and a memorycoupled with the processor. The processor effectuates operationsincluding receiving a route request. The processor further effectuatesoperations including routing the request to a node using a mapping ofsubscription information. The processor further effectuates operationsincluding receiving an overload report for one or more interfaces. Theprocessor further effectuates operations including in response toreceiving the overload report, re-routing a device trigger from a firsthome subscriber server (HSS) to a second HSS.

In embodiments, a method comprises receiving, by a processor, a routerequest. The method further includes routing, by the processor, theroute request to a node using a mapping of subscription information. Themethod further includes receiving, by the processor, an overload reportfor one or more interfaces. The method further includes in response toreceiving the overload report, re-routing, by the processor, a devicetrigger from a first home subscriber server (HSS) to a second HSS.

In embodiments, a computer readable storage medium stores computerexecutable instructions that when executed by a computing device causesaid computing device to effectuate operations including receiving aroute request. Operations further include routing the request to a nodeusing a mapping of subscription information. Operations further includereceiving an overload report for one or more interfaces. Operationsfurther include, in response to receiving the overload report,re-routing a device trigger from a first home subscriber server (HSS) toa second HSS.

These and other embodiments are described in greater detail elsewhereherein.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide an understanding ofthe variations in implementing the disclosed technology. However, theinstant disclosure may take many different forms and should not beconstrued as limited to the examples set forth herein. Where practical,like numbers refer to like elements throughout.

FIG. 1 illustrates a block diagram of an example network employingaspects of the disclosure herein.

FIG. 2A illustrates a block diagram of an example network employingaspects of the disclosure herein.

FIG. 2B illustrates another block diagram of an example networkemploying aspects of the disclosure herein.

FIG. 2C illustrates a further block diagram of an example networkemploying aspects of the disclosure herein.

FIG. 3 illustrates an example methodology depicting aspects disclosedherein.

FIG. 4 is a representation of an example network includingvirtualization.

FIG. 5 depicts an example communication system that provides wirelesstelecommunication services over wireless communication networks.

FIG. 6 depicts an example communication system that provides wirelesstelecommunication services over wireless communication networks.

FIG. 7 is an example system diagram of a radio access network and a corenetwork.

FIG. 8 illustrates an example architecture of a GPRS network.

FIG. 9 is a block diagram of an example public land mobile network(PLMN).

DETAILED DESCRIPTION

Aspects herein are directed to systems and methods for managing machineto machine (M2M) communication in networks, and particularly involve anetworking function, such as a machine type communication (MTC)interworking function (IWF) (referred to together as “MTC-IWF”).

One challenge associated with the growth in signaling traffic due toincreasing numbers of IoT devices is the potential for signaling stormswhich disrupt the core network elements including their functional andoperational integrity. Legacy networks lacking flexible mappingfunctions, dynamic network monitoring, overload detection, andprotection mechanisms for handling signaling protocols that are used tocarry M2M traffic may result in unforeseen service impacts across one ormore industry verticals. Solutions must be implemented across a widerange of platforms or be interoperable with various platforms as M2Msystems contemplated herein will leverage a variety of connection meansand other resources, such as LTE/LTE-Advanced (LTE/LTE), 5G capablevirtual network infrastructure, and 3GPP/IETF defined capabilitieswithin the access and core network elements as well as the databasesystems, as well as aspects disclosed herein such as interworkingfunctions, application servers, their programmable applicationprogramming interfaces (APIs) and other interfaces.

When enabled, cellular M2M devices are registered in the mobility corenetwork home subscriber server (HSS) before they gain access to anyspecific application related to their IoT functionality or capabilitiesvia the M2M application server (AS). When a large volume of M2M devicesare triggered by their ASs, the serving MTC-IWF needs to interact withthe HSS on an interface (e.g., S6m diameter interface) to identify thesubscriber and its serving core network nodes in the network to routethe subscriber information requests (SIR). The HSS may be handlingseveral other interfaces (e.g., diameter interfaces) towards the corenetwork elements at the same time, which may result in overload orresource preemption conditions resulting from M2M SIR triggering inexcess of particular volumes. In accordance with aspects herein,accurate mapping of M2M devices within the MTC-IWF based on subscriptionretrieval information from the HSS can be used to ensure the devicetriggers are routed to the correct serving nodes. While aspects hereinare described in terms of HSSs, these can more generally refer to anyentity databases containing relevant entity information relating tolocation, subscriptions, permissions, attributes, et cetera.

A dynamic mapping function can be used in a MTC-IWF. The mappingfunction is capable of retrieving the subscription information from theHSS and mapping it to the external identity that it receives from agiven application server or set of servers. The mapping function iscapable of adaptively updating its context information as the networkfunctions are dynamically instantiated in data centers. In addition,based on a closed-loop layered dynamic overload control detection andprotection mechanism that works in conjunction with both MTC-IWF and HSSnetwork elements, the mapping function facilitates MTC-IWF routing ofdevice triggers toward mobility management entities (MMEs) or edgesignaling gateways that will eventually serve the devices. “Devicetrigger” is used generally to refer to a wide variety of activity.“Application request” may also be used in this regard, referring toone-way or two-way interactions between transmission originators andrecipients in networks described. Further, with regard to feedbackreceived from network elements and other aspects, “communicationattributes” can be monitored. While varying terms are used herein forpurposes of example, communication attributes can be aspects such as,e.g., peer (or other) node traffic utilization, proximity, routingcomplexity, transport latency, interface traffic data, equipmentcondition, et cetera. Communication attributes can be analyzed andemployed herein based on historical, current, or projected metrics.

In high-speed mobility networks carrying M2M traffic, the M2Mapplication (which can be, e.g., within the UE or leveraged by UE whilehosted elsewhere) interacts with M2M application servers that arededicated to serve a given type or class of IoT devices. Suchcommunication be carried, e.g., on the control plane, on the user plane,or others. These communications utilize 3GPP standards definedinterfaces between the individual network elements within the mobilitynetworks.

In LTE/LTE-A mobile operator network environments, IoT devices, whenenabled in a given coverage area, can procure radio resource control(RRC) connections by the serving radio access network (RAN) andthereafter attach to a serving MME upon completing the authenticationand location exchange procedures. Connectivity to the serving MME isutilized when these devices are triggered for specific actions by aserving AS.

The M2M ASs are connected to the serving capability servers (SCSs). TheSCSs are controlled by, e.g., a MTC provider or a mobile operator, andinterface with the MTC-IWF over an interface (e.g., Tsp diameterinterface). The MTC-IWF can interact with the HSS on an alternativeinterface (e.g., S6m diameter interface). For each trigger for an IoTdevice (or device group), the serving MTC-IWF needs to identify aserving MME for that specific device (or group of devices) to initiatecommunication (e.g., on a control plane) via an interface (e.g., T5bdiameter interface). The MTC-IWF needs to be MME topology-aware tofacilitate routing of device triggers as these can be transitioned intoor implemented as virtualized network functions and may be instantiatedin data centers on demand based on traffic dynamics and resourcemanagement.

These and other aspects are illustrated in, e.g., FIG. 1, showing aportion of a network 100 including MTC-IWF 110 having mapping function112. A variety of other elements show interaction and communicationbetween network elements. Throughout FIG. 1, various interfaces (e.g.,diameter interfaces) are indicated along communication lines. However,while shown as such to illustrate one possible embodiment, these shouldnot be construed as limiting, as other interfaces or communication meanscan be utilized herewith without departing from the scope or spirit ofthe innovation.

M2M AS 156 (or multiple M2M application servers) can be connected tonetwork 130 (e.g., the Internet, proprietary networks) providingconnectivity to packet data network gateway (PGW) 166, therebyestablishing communication with the core or regional carrier network.PGW 166 is communicatively coupled with at least SCS 158 and servinggateway (SGW) 168. SCS 158 is communicatively coupled with the MTC-IWF110. SGW 168 is communicatively coupled with MME 176 and various accesspoints such as eNodeBs 186.

MME 176 can also be operatively coupled with, e.g., various accesspoints such as eNodeBs 186, Home eNodeBs (HeNodeBs) 184, serving generalpacket radio service (GPRS) support node (SGSN) 178, and HSS 120, aswell as the MTC-IWF 110. SGSN 178 can also be communicatively coupledwith Universal Terrestrial Radio Access Network (UTRAN) nodes 188.

HSS 120 is communicatively coupled with SGSN 178 and MTC AAA 162. HSS120 is also communicatively coupled with MTC-IWF 110, which itself canalso be coupled with short message service center (SMSC) 164 andcharging data function/charging gateway function (CDF/CGF) 160.

A variety of UE connects to this architecture. One or more devices of 3GM2M UE 198 can connect to the network using UTRAN nodes 188. Various4G/LTE devices such as LTE M2M UE 196 and 194 connect through eNodeBs186. These can also be communicatively coupled in embodiments to LTEsmall cells such as LTE small cell 192 or 190. LTE small cells 192 and190 can connect to the carrier network using HeNodeBs 184.

FIG. 1 and other drawings herein illustrate a variety of connections forcarrying communications. To the extent that the communications have anoriginating sender and target recipient, “intermediary network elements”can be used generally to refer to any variety of elements through whichthe communication is transmitted, or which support routing and deliveryof the transmission. For example, where an AS sends an applicationrequest, the SCS can be an intermediary element, and where UE sends anapplication request, the RAN and/or MME can be intermediary elements.

In some carrier networks, there may be multiple combination pairs of M2MASs and SCSs that may interact with several virtualized instances ofMTC-IWFs in a distributed arrangement. These MTC-IWFs can connect to adedicated virtual HSS, distributed HSS pairs, or multiple HSSs for IoTapplications. As these virtual instances may be created or destroyedbased on, e.g., traffic dynamics, mapping of such instances as well assubscription identities facilitate routing of device triggers in ahigh-speed mobility network. Device triggering, when initiated byseveral M2M AS-SCS pairs at the same time via the MTC-IWF on aparticular interface (e.g., S6m interface) may drive an HSS intooverload, such as if an HSS is already processing several othertransactions over multiple signaling interfaces to provide mobilitytriple/quad-play services.

In this regard, FIGS. 2A to 2C illustrate additional embodiments ofnetworks 200, 200′, and 200″ having multiple ASs, SCSs, MTC-IWFs, and/orHSSs. While network elements of FIGS. 2A to 2C are shown with likeelement numbering, it is understood that element numbers may refer to atype or class of network element, and that single number may representmultiple instances or variations of elements within the type or class.For example, in FIG. 2C, pools or groups of MTC-IWFs and/or HSSs can beemployed in a mesh topology.

Throughout FIGS. 2A to 2C, various interfaces (e.g., diameterinterfaces) are indicated along communication lines. However, whileshown as such to illustrate one possible embodiment, these should not beconstrued as limiting, as other interfaces or communication means can beutilized herewith without departing from the scope or spirit of theinnovation.

With specific regard to FIG. 2A, an embodiment with multiple applicationservers corresponding to multiple UE devices interacting with associatedapplications is illustrated. M2M AS A1 298, M2M AS A2 296, and M2M AS AN294 represent application servers 1 to N for application A. Similarly,M2M AS B1 292, M2M AS B2 290, and M2M AS BN 288 represent applicationservers 1 to N for application B, and M2M AS C1 286, M2M AS C2 284, andM2M AS CN 282 represent application servers 1 to N for application C.MTC UE A 228 can interact with application A, MTC UE B 230 withapplication B, and MTC UE C 232 with application C, via network 200 asconnected through RAN 226. M2M AS A1 298, M2M AS A2 296, and M2M AS AN294 connect to network 200 using SCS A 280, M2M AS B1 292, while M2M ASB2 290, and M2M AS BN 288 connect through SCS B 278, and M2M AS Cl 286,M2M AS C2 284, and M2M AS CN 282 connect through SCS C 276.

SCS A 280, SCS B 278, and SCS C 276 (and/or any other SCSs associatedwith additional ASs) are communicatively coupled with MTC-IWF 210including mapping function 212. MTC-IWF 210 is also coupled with HSS220, which may be a virtualized instance of a HSS. Both MTC-IWF 210 andHSS 220 can be coupled with feedback controls 222. MTC-IWF 210 is alsocommunicatively coupled with the carrier network core or regionalnetwork, e.g., MME/SGSN/message service center (MSC) 224, whichcommunicates to UE via RAN 226.

FIG. 2B illustrates a further embodiment of network 200′. While severalelements are similar, network 200′ includes two MTC-IWFS, MTC-IWF 210having mapping function 212 and MTC-IWF 214 having mapping function 216.These communicate with an HSS pair comprised of HSS 220 and HSS 234,where layered feedback controls 222 pass feedback from HSS 220 and/orHSS 234 to MTC-IWF 210 and/or MTC-IWF 214. FEEDBACK CONTROLS CAN PROTECTAGAINST OL OVERLOAD

FIG. 2C illustrates yet a further embodiment of network 220″ havingresource pools. Specifically, network 220″ includes the generalizedblock diagram illustrated having a mesh of MTC-IWFs interacting withHSSs for load sharing. The pools can be arranged based on, e.g.,geography or other parameters to allow organization of different serviceportions.

Particularly, the portions of network 220″ illustrated show MTC-IWFpools 1 to M. MTC-IWF Pool 1 241 includes mapping function 242, as wellas MTC-IWF group 1 244 including two or more MTC-IWF instances includingMTC-IWF 11 243 and MTC-IWF 1N 245. MTC-IWF Pool 2 246 includes mappingfunction 247, as well as MTC-IWF group 2 249 including two or moreMTC-IWF instances including MTC-IWF 21 248 and MTC-IWF 2N 250. MTC-IWFPool M 251 includes mapping function 252, as well as MTC-IWF group M 254including two or more MTC-IWF instances including MTC-IWF M1 253 andMTC-IWF MN 255. While the MTC-IWF pools are shown as including a singlegroup of 1 to M MTC-IWFs, different numbers, or two or more groups ofMTC-IWFs can be included in pools. Further, while three pools areillustrated in the MTC-IWF mesh, different numbers of pools can beincluded without departed from the scope or spirit of the innovation.

The MTC-IWF pools communicate across interfaces to HSS pools to extractsubscriber information supporting routing and mapping of requestsoriginating at UE or interacting ASs. Particularly, three HSS pools—HSSpool X 256, HSS pool Y 263, and HSS pool Z 270 are illustrated. HSS poolX 256 includes two HSS pairs, HSS group X1 258 including HSS X11 257 andHSS X12 259, and HSS group X2 261 including HSS X21 260 and HSS X22 262.HSS pool Y 263 includes two HSS pairs, HSS group Y1 265 including HSSY11 264 and HSS Y12 266, and HSS group Y2 268 including HSS Y21 267 andHSS Y22 269. HSS pool Z 270 includes two HSS pairs, HSS group Z1 272including HSS Z11 271 and HSS Z12 273, and HSS group Z2 275 includingHSS Z21 274 and HSS Z22 276. While the HSS pools are shown as includinga HSS pairs, different-sized groups can be included in each pool, anddifferent numbers of groups (e.g., more than two pairs, more than twogroups) can be included in a pool. Further, while pools X, Y, and Z areillustrated different numbers of pools can be included without departedfrom the scope or spirit of the innovation.

With these example networks explained, function of aspects of theMTC-IWF can be better described. MTC-IWFs (e.g., 110, 210, 214,illustrated pools) allow varying ASs (156, 298, et cetera) fromdifferent industry verticals or contexts to interact with UE (198, 196,190, 228, et cetera) across mobile networks by ensuring MTC is properlyhandled according to network-defined functions or protocols. Generally,then, MTC-IWFs provide IoT devices serviceability across data networks.

When an AS originates a trigger or query to UE (e.g., a single device orclass/group of devices identified by manufacturer, model, uniqueexternal identifier, software, location, users, et cetera) utilizingassociated software or functionality, or UE originates a trigger orquery to an AS associated with its software or functionality, it must berouted through the network. This may travel through an intermediaryelement—on the UE side, a RAN (e.g., RAN 226) or on the AS side, an SCS(e.g., 280, 158), and/or other elements in either situation—beforearriving at the MTC-IWF which handles and routes the trigger or query.

This handling and routing are facilitated by the mapping function (e.g.,112, 212, 216) of the MTC-IWF. The mapping function maps externalidentifiers (or other unique IDs such as an international mobileequipment identity) for UE and ASs to facilitate traffic routing andservice provisioning.

Static mapping of user subscriptions to external identities associatedwith application providers/SCSs may not provide comprehensive and rapidrouting because virtualized functions associated with services may bedynamically instantiated and de-instantiated (e.g., based on usage,based on sessions, to share resources). Therefore, the mapping functionof the MTC-IWF is a dynamic mechanism that maintains informationdefining virtualized network topology and subscription-to-identitymapping for UE and ASs to facilitate routing decisions by the MTC-IWFfor requests from UE or ASs. This can be performed over an interfacesuch as the S6m interface supporting IoT communications to supportscalability, service roll-out, dynamic mapping, overload detection, andprotection mechanisms.

To this end, the mapping function extracts user subscription informationfrom an associated HSS (e.g., 120, 220, 234, or pools 256, 263, 270)based on an external trigger (e.g., from an AS or UE) and identitymapping. Mappings are updated in real-time to track changes to networktopology and configuration. Using these mappings, the MTC-IWF routesrequests to a correct serving node and ultimately the intended target.Dynamic closed-loop feedback controls between the MTC-IWF and HSS alongwith the mapping function facilitate re-routing of particular interfacetraffic (e.g., on S6m) to/from an MTC-IWF based on specific triggersfrom pairs of ASs and SCSs to alternate HSS and MME systems, maintainingthe virtualized network topology mapping.

The mapping function or other modules of the MTC-IWF can also trackindividual requests by associating requests (e.g., triggers, queries)with a request reference number and the request state in terms ofcompletion or status. This can allow requests to be timed out,cancelled, recalled, dropped, superseded, et cetera, depending on theactivity of network elements and users.

The mapping function can also maintain state information related tovarious network elements or interfaces. For example, the mappingfunction can determine or handle load factors to provide information tofeedback mechanisms used by the MTC-IWF for routing and trafficmanagement. Load factors can be monitored continuously, based onconditions, or at periodic intervals.

The mapping function can also work with legacy systems or updatedversions thereof. For example, interacting with a SMSC, the mappingfunction may determine routing, through the MTC-IWF, to deliver a shortmessage service (SMS) message to a device on a carrier different fromthat of the message-originating UE.

FIG. 3 illustrates a flow chart of an example methodology 300 capturingthese aspects. Methodology 300 begins at 302 and proceeds to 304 where arequest is generated. The request may be generated by an applicationserver triggering or querying user equipment (a single device or group),by user equipment seeking to trigger or query an application server (orother user equipment), or at other points within the network.

Methodology 300 may thereafter, in embodiments, proceed to 304 where anintermediary element or multiple intermediary elements communicativelycoupled with the originating element can receive and transmit therequest. If the AS originates the request, the request may be passed to,e.g., an SCS associated with the AS. If UE originates the request, therequest may be passed to, e.g., a RAN or access point, and thereafter aMME or SGSN.

At 308, the request is passed to an MTC-IWF. The MTC-IWF handlesmanagement of the request by performing any necessary translation,interpretation, conversion, et cetera, of the request to ensure itconforms with network-defined functions or other standards of thenetwork. In embodiments, the request can be provided in a format notrequiring such processing, or may be processed before reaching theMTC-IWF.

A mapping function of the MTC-IWF generates and/or maintains a mappingof network topology including unique identifiers for ASs and UE. TheMTC-IWF possesses knowledge of the serving HSS in multiple-HSSembodiments, and information for the mapping can be extracted from theHSS. The mapping includes subscription information, sourced from an HSS,to track application provisioning, authentication, et cetera. Themapping can also include load data and other metrics.

Thereafter, at 312, mapping data related to the request is providedthrough the MTC-IWF. This mapping data includes target information(e.g., receiving UE or AS) and serving node information for reaching thetarget. With this mapping data, the MTC-IWF determines routing for therequest and proceeds with routing the request according to thedetermination.

In some embodiments, the request and associated information determinedby the MTC-IWF can be passed through intermediary elements en-route toits target. In examples where an AS request is being directed to UE, theMTC-IWF may pass the information to a MME and/or RAN. In examples wherea UE request is being directed to an AS, the MTC-IWF may pass theinformation to an SCS. Thereafter, the request is passed to the targetat 316, and methodology 300 can end at 318.

Various alternative or complementary embodiments can be utilized inconjunction with the illustrated figures. In embodiments, the HSS canalso be used for authenticating ASs, UE, and/or triggers therefrom.

In embodiments, particularly including a large volume of UE belonging toa mapped sub-group within a group or across multiple sets of groups tobe triggered with subscriber requests (e.g., from a service provider),the serving AS and SCS nodes can interact with the MTC-IWF on apre-defined mapping or via intelligent learning. To avoid overloads fromwide-ranging requests, one or more HSSs can include standalone overloadcontrols based on internal resource (e.g., processor, memory, interfaceutilization) evaluation. The overload controls can include functionalityto report back to the MTC-IWF to reduce traffic over the impactedinterface. The HSS may send such overload reports based on a staticconfiguration and in response to requests from the MTC-IWF inembodiments where the HSS only interacts with the MTC-IWF throughresponses to queries from the MTC-IWF. The HSS can further monitor otheractive interfaces during overload for prioritization and messageshedding but may still be unable to resolve particular issues (e.g., ifit cannot validate cross-layered (application/diameter/SCTP-transport)monitoring, detection and protection on each of the interfaces in acoordinated manner interworking with the peer nodes. This can beresolved through implementation of an integrated closed-loop dynamicfeedback control system and cross-layered protocol monitoring.

In particular, through monitoring the interface (e.g., S6m) utilizationon the HSS across operational peer MTC-IWF nodes, in conjunction withits internal resource monitoring (e.g., at time intervals, which can beshorter than other monitoring intervals; and/or on condition) andcreating a dynamic mapping configuration of cross-layered protocolresources within the node, detection of impending overload triggers andutilization of appropriate protection schemes so as to mitigate adversenode, peer-node functional and end-to-end service impacts can beimplemented.

An HSS ingress can protect itself intelligently by requesting re-routingof the device trigger information from the serving MTC-IWF to analternate HSS or group of HSS nodes that are in close proximitydetermined via round trip time (RTT) latency evaluation. The MTC-IWF mayutilize the overload reports from an HSS egress to re-route any newAS-SCS based device triggers to alternate HSS systems, apply back-offalgorithms (e.g., a random back-off algorithm) based on the priority ofthe incoming requests so as to avoid saturating the HSS, start internalmessage prioritization and shedding of low priority requests for acertain group of devices based on their device type, service criticalityand its usage, or take other action, et cetera.

Using a closed-loop monitoring system, the HSS can provide dynamicfeedback controls to each of its MTC-IWF diameter peer nodes at regularintervals during the diameter transactions exchange so that each of theMTC-IWFs can apply internal diameter message rate throttling mechanismsbased on their specific system attributes and constrain aggregateoutbound diameter traffic flow and per-diameter interface traffic flowto volumes avoiding saturation internally and toward any peer HSS. Thetechniques above and elsewhere herein can generally be characterized asmitigating overload conditions or other network issues.

In an embodiment, after the MTC-IWF obtains a serving node identity fora given M2M device (e.g., UE), the MTC-IWF can trigger a control planerequest, via interfaces such as T5 (T5a/T5b/T5c) diameter interfaces,towards a respective core network node based on the radio access type inwhich the device is camped. During mobility scenarios, if the M2M devicechanges location, the MTC-IWF could select the current serving nodebased on dynamic methods (e.g., DNS-based selection) or could use analternate mapping means.

With particular focus on the mapping function, the MTC-IWF mappingfunction can build, in real-time, an integrated view of the external ASidentity to UE (e.g., international mobile subscriber identity and/orIMEI). If the UE supports multiple applications (each of which arecharacterized by a unique identity from a unique application server orgroup of application servers) the MTC-IWF extracts the identity from thevirtualized HSS and updates its mapping table.

The serving node is extracted (e.g., MME in case of LTE radio accesstechnology) from the HSS and the mapping table is updated with theserving node. Thereafter analysis of the mapping table is performed toroute the trigger, accounting for other systemic attributes such as itspeer node traffic utilization, proximity, routing complexity, transportlatency, et cetera. After the serving MME node receives the devicetrigger, it can initiate a connection towards the end user (IoT device)based on its internal mapping function that has the serving cellinformation. Similar techniques are used in UE to AS communication.

As multiple virtual instances of core network functions are created indata centers, the dynamic mapping function within the MTC-IWF canmaintain the identity mapping (external application to usersubscription) as well as the downstream network topology mapping, usinga synthesized version of this mapping to be able for routing devicetrigger requests.

In embodiments, the mapping function within the MTC-IWF can also beintegrated with a RAN database function that has access to the list ofLTE RAN nodes associated with a tracking area (and/or multiple trackingareas). Based on this information of the edge serving RAN nodes andgeographic distribution, the mapping function can further proactivelyanalyze the target device real-time location information received fromthe HSS via, e.g., an S6m interface to deliver and/or back-off in caseof particular conditions (e.g., an emergency) in that area.

In embodiments, the mapping function and/or MTC-IWF can be used toenforce priority or quality of service requirements. In alternative orcomplementary embodiments, analytics based on activity performed by theMTC-IWF or associated mapping function, or data collected thereby, canbe reported and/or interpreted for monetization.

FIGS. 4-9 show a variety of aspects used in conjunction with orproviding context for M2M communication and the MTC IWF. Particularly,FIG. 4 describes virtualization in the context of instances describedabove, and FIGS. 5-9 show various computing and network environmentswith which aspects herein are compatible.

FIG. 4 is a representation of an example network 400. Network 400 maycomprise an SDN, for example, network 400 may include one or morevirtualized functions implemented on general purpose hardware, such asin lieu of having dedicated hardware for every network function. Thatis, general purpose hardware of network 400 may be configured to runvirtual network elements to support communication services, such asmobility services, including consumer services and enterprise services.These services may be provided or measured in sessions.

A virtual network functions (VNFs) 402 may be able to support a limitednumber of sessions. Each VNF 402 may have a VNF type that indicates itsfunctionality or role. For example, FIG. 4 illustrates a gateway VNF 402a and a policy and charging rules function (PCRF) VNF 402 b.Additionally or alternatively, VNFs 402 may include other types of VNFs.Each VNF 402 may use one or more virtual machines (VMs) 404 to operate.Each VM 404 may have a VM type that indicates its functionality or role.For example, FIG. 4 illustrates a MCM VM 404 a, an ASM VM 404 b, and aDEP VM 404 c. Additionally or alternatively, VMs 404 may include othertypes of VMs. Each VM 404 may consume various network resources from ahardware platform 406, such as a resource 408, a virtual centralprocessing unit (vCPU) 408 a, memory 408 b, or a network interface card(NIC) 408 c. Additionally or alternatively, hardware platform 406 mayinclude other types of resources 408.

While FIG. 4 illustrates resources 408 as collectively contained inhardware platform 406, the configuration of hardware platform 406 mayisolate, for example, certain memory from other memory 108 c.

Hardware platform 406 may comprise one or more chasses 410. Chassis 410may refer to the physical housing or platform for multiple servers orother network equipment. In an aspect, chassis 410 may also refer to theunderlying network equipment. Chassis 410 may include one or moreservers 412. Server 412 may comprise general purpose computer hardwareor a computer. In an aspect, chassis 410 may comprise a metal rack, andservers 412 of chassis 410 may comprise blade servers that arephysically mounted in or on chassis 410.

Each server 412 may include one or more network resources 408, asillustrated. Servers 412 may be communicatively coupled together (notshown) in any combination or arrangement. For example, all servers 412within a given chassis 410 may be communicatively coupled. As anotherexample, servers 412 in different chasses 410 may be communicativelycoupled. Additionally or alternatively, chasses 410 may becommunicatively coupled together (not shown) in any combination orarrangement.

The characteristics of each chassis 410 and each server 412 may differ.The type or number of resources 410 within each server 412 may vary. Inan aspect, chassis 410 may be used to group servers 412 with the sameresource characteristics. In another aspect, servers 412 within the samechassis 410 may have different resource characteristics.

Given hardware platform 406, the number of sessions that may beinstantiated may vary depending upon how efficiently resources 408 areassigned to different VMs 404. For example, assignment of VMs 404 toparticular resources 408 may be constrained by one or more rules. Forexample, a first rule may require that resources 408 assigned to aparticular VM 404 be on the same server 412 or set of servers 412. Forexample, if VM 404 uses eight vCPUs 408 a, 1 GB of memory 408 b, and 2NICs 408 c, the rules may require that all of these resources 408 besourced from the same server 412. Additionally or alternatively, VM 404may require splitting resources 408 among multiple servers 412, but suchsplitting may need to conform with certain restrictions. For example,resources 408 for VM 404 may be able to be split between two servers412. Default rules may apply. For example, a default rule may requirethat all resources 408 for a given VM 404 must come from the same server412.

An affinity rule may restrict assignment of resources 408 for aparticular VM 404 (or a particular type of VM 404). For example, anaffinity rule may require that certain VMs 404 be instantiated on (forexample, consume resources from) the same server 412 or chassis 410. Forexample, if VNF 402 uses six MCM VMs 404 a, an affinity rule may dictatethat those six MCM VMs 404 a be instantiated on the same server 412 (orchassis 410). As another example, if VNF 402 uses MCM VMs 404 a, ASM VMs404 b, and a third type of VMs 404, an affinity rule may dictate that atleast the MCM VMs 404 a and the ASM VMs 404 b be instantiated on thesame server 412 (or chassis 410). Affinity rules may restrict assignmentof resources 408 based on the identity or type of resource 408, VNF 402,VM 404, chassis 410, server 412, or any combination thereof.

An anti-affinity rule may restrict assignment of resources 408 for aparticular VM 404 (or a particular type of VM 404). In contrast to anaffinity rule—which may require that certain VMs 404 be instantiated onthe same server 412 or chassis 410—an anti-affinity rule requires thatcertain VMs 404 be instantiated on different servers 412 (or differentchasses 410). For example, an anti-affinity rule may require that MCM VM404 a be instantiated on a particular server 412 that does not containany ASM VMs 404 b. As another example, an anti-affinity rule may requirethat MCM VMs 404 a for a first VNF 402 be instantiated on a differentserver 412 (or chassis 410) than MCM VMs 404 a for a second VNF 402.Anti-affinity rules may restrict assignment of resources 408 based onthe identity or type of resource 408, VNF 402, VM 404, chassis 410,server 412, or any combination thereof.

Within these constraints, resources 408 of hardware platform 406 may beassigned to be used to instantiate VMs 404, which in turn may be used toinstantiate VNFs 402, which in turn may be used to establish sessions.The different combinations for how such resources 408 may be assignedmay vary in complexity and efficiency. For example, differentassignments may have different limits of the number of sessions that canbe established given a particular hardware platform 406.

For example, consider a session that may require gateway VNF 402 a andPCRF VNF 402 b. Gateway VNF 402 a may require five VMs 404 instantiatedon the same server 412, and PCRF VNF 402 b may require two VMs 404instantiated on the same server 412. (In embodiments no affinity oranti-affinity rules restrict whether VMs 404 for PCRF VNF 402 b may ormust be instantiated on the same or different server 412 than VMs 404for gateway VNF 402 a.) In this example, each of two servers 412 mayhave sufficient resources 408 to support 10 VMs 404. To implementsessions using these two servers 412, first server 412 may beinstantiated with 10 VMs 404 to support two instantiations of gatewayVNF 402 a, and second server 412 may be instantiated with 9 VMs: fiveVMs 404 to support one instantiation of gateway VNF 402 a and four VMs404 to support two instantiations of PCRF VNF 402 b. This may leave theremaining resources 408 that could have supported the tenth VM 404 onsecond server 412 unused (and unusable for an instantiation of either agateway VNF 402 a or a PCRF VNF 402 b). Alternatively, first server 412may be instantiated with 10 VMs 404 for two instantiations of gatewayVNF 402 a and second server 412 may be instantiated with 10 VMs 404 forfive instantiations of PCRF VNF 402 b, using all available resources 408to maximize the number of VMs 404 instantiated.

Consider, further, how many sessions each gateway VNF 402 a and eachPCRF VNF 402 b may support. This may factor into which assignment ofresources 408 is more efficient. For example, consider if each gatewayVNF 402 a supports two million sessions, and if each PCRF VNF 402 bsupports three million sessions. For the first configuration—three totalgateway VNFs 402 a (which satisfy the gateway requirement for sixmillion sessions) and two total PCRF VNFs 402 b (which satisfy the PCRFrequirement for six million sessions)—would support a total of sixmillion sessions. For the second configuration—two total gateway VNFs402 a (which satisfy the gateway requirement for four million sessions)and five total PCRF VNFs 402 b (which satisfy the PCRF requirement for15 million sessions)—would support a total of four million sessions.Thus, while the first configuration may seem less efficient looking onlyat the number of available resources 408 used (as resources 408 for thetenth possible VM 404 are unused), the second configuration is actuallymore efficient from the perspective of being the configuration that cansupport more the greater number of sessions.

To solve the problem of determining a capacity (or, number of sessions)that can be supported by a given hardware platform 405, a givenrequirement for VNFs 402 to support a session, a capacity for the numberof sessions each VNF 402 (e.g., of a certain type) can support, a givenrequirement for VMs 404 for each VNF 402 (e.g., of a certain type), agive requirement for resources 408 to support each VM 404 (e.g., of acertain type), rules dictating the assignment of resources 408 to one ormore VMs 404 (e.g., affinity and anti-affinity rules), the chasses 410and servers 412 of hardware platform 406, and the individual resources408 of each chassis 410 or server 412 (e.g., of a certain type), aninteger programming problem may be formulated.

First, a plurality of index sets may be established. For example, indexset L may include the set of chasses 410. For example, if a systemallows up to 6 chasses 410, this set may be:

-   L={1, 2, 3, 4, 5, 6},    where l is an element of L.

Another index set J may include the set of servers 412. For example, ifa system allows up to 16 servers 412 per chassis 410, this set may be:

-   J={1, 2, 3, . . . , 16},    where j is an element of J.

As another example, index set K having at least one element k mayinclude the set of VNFs 402 that may be considered. For example, thisindex set may include all types of VNFs 402 that may be used toinstantiate a service. For example, let

-   K={GW, PCRF}    where GW represents gateway VNFs 402 a and PCRF represents PCRF VNFs    402 b.

Another index set I(k) may equal the set of VMs 404 for a VNF 402 k.Thus, let

-   I(GW)={MCM, ASM, IOM, WSM, CCM, DCM}    represent VMs 404 for gateway VNF 402 a, where MCM represents MCM VM    404 a, ASM represents ASM VM 404 b, and each of IOM, WSM, CCM, and    DCM represents a respective type of VM 404. Further, let-   I(PCRF)={DEP, DIR, POL, SES, MAN}    represent VMs 404 for PCRF VNF 402 b, where DEP represents DEP VM    404 c and each of DIR, POL, SES, and MAN represent a respective type    of VM 404.

Another index set V may include the set of possible instances of a givenVM 404. For example, if a system allows up to 20 instances of VMs 404,this set may be:

-   V={1, 2, 3, . . . , 20},    where v is an element of V.

In addition to the sets, the integer programming problem may includeadditional data. The characteristics of VNFs 402, VMs 404, chasses 410,or servers 412 may be factored into the problem. This data may bereferred to as parameters. For example, for given VNF 402 k, the numberof sessions that VNF 402 k can support may be defined as a functionS(k). In an aspect, for an element k of set K, this parameter may berepresented by

-   S(k)>=0;    is a measurement of the number of sessions k can support. Returning    to the earlier example where gateway VNF 402 a may support 2 million    sessions, then this parameter may be S(GW)=2,000,000.

VM 404 modularity may be another parameter in the integer programmingproblem. VM 404 modularity may represent the VM 404 requirement for atype of VNF 402. For example, for k that is an element of set K and ithat is an element of set I, each instance of VNF k may require M(k, i)instances of VMs 404. For example, recall the example where

-   I(GW)={MCM, ASM, IOM, WSM, CCM, DCM}.    In an example, M(GW, I(GW)) may be the set that indicates the number    of each type of VM 404 that may be required to instantiate gateway    VNF 402 a. For example,-   M(GW, I(GW))={2, 16, 4, 4, 2, 4}    may indicate that one instantiation of gateway VNF 402 a may require    two instantiations of MCM VMs 404 a, 16 instantiations of ACM VM 404    b, four instantiations of IOM VM 404, four instantiations of WSM VM    404, two instantiations of CCM VM 404, and four instantiations of    DCM VM 404.

Another parameter may indicate the capacity of hardware platform 406.For example, a parameter C may indicate the number of vCPUs 408 arequired for each VM 404 type i and for each VNF 402 type k. Forexample, this may include the parameter

-   C(k, i).    For example, if MCM VM 404 a for gateway VNF 402 a requires 20 vCPUs    408 a, this may be represented as-   C(GW, MCM)=20.

However, given the complexity of the integer programming problem—thenumerous variables and restrictions that must be satisfied—implementingan algorithm that may be used to solve the integer programming problemefficiently, without sacrificing optimality, may be difficult.

FIG. 5 illustrates a functional block diagram depicting one example ofan LTE-EPS network architecture 500 that may be at least partiallyimplemented as an SDN. Network architecture 500 disclosed herein isreferred to as a modified LTE-EPS architecture 500 to distinguish itfrom a traditional LTE-EPS architecture.

An example modified LTE-EPS architecture 500 is based at least in parton standards developed by the 3rd Generation Partnership Project (3GPP),with information available at www.3gpp.org. LTE-EPS network architecture500 may include an access network 502, a core network 504, e.g., an EPCor Common Back Bone (CBB) and one or more external networks 506,sometimes referred to as PDN or peer entities. Different externalnetworks 506 can be distinguished from each other by a respectivenetwork identifier, e.g., a label according to DNS naming conventionsdescribing an access point to the PDN. Such labels can be referred to asAccess Point Names (APN). External networks 506 can include one or moretrusted and non-trusted external networks such as an internet protocol(IP) network 508, an IP multimedia subsystem (IMS) network 510, andother networks 512, such as a service network, a corporate network, orthe like. In an aspect, access network 502, core network 504, orexternal network 506 may include or communicate with a network.

Access network 502 can include an LTE network architecture sometimesreferred to as Evolved Universal mobile Telecommunication systemTerrestrial Radio Access (E UTRA) and evolved UMTS Terrestrial RadioAccess Network (E-UTRAN). Broadly, access network 502 can include one ormore communication devices, commonly referred to as UE 514, and one ormore wireless access nodes, or base stations 516 a, 516 b. Duringnetwork operations, at least one base station 516 communicates directlywith UE 514. Base station 516 can be an evolved Node B (e-NodeB), withwhich UE 514 communicates over the air and wirelessly. UEs 514 caninclude, without limitation, wireless devices, e.g., satellitecommunication systems, portable digital assistants (PDAs), laptopcomputers, tablet devices and other mobile devices (e.g., cellulartelephones, smart appliances, and so on). UEs 514 can connect to eNBs516 when UE 514 is within range according to a corresponding wirelesscommunication technology.

UE 514 generally runs one or more applications that engage in a transferof packets between UE 514 and one or more external networks 506. Suchpacket transfers can include one of downlink packet transfers fromexternal network 506 to UE 514, uplink packet transfers from UE 514 toexternal network 506 or combinations of uplink and downlink packettransfers. Applications can include, without limitation, web browsing,VoIP, streaming media and the like. Each application can pose differentQuality of Service (QoS) requirements on a respective packet transfer.Different packet transfers can be served by different bearers withincore network 504, e.g., according to parameters, such as the QoS.

Core network 504 uses a concept of bearers, e.g., EPS bearers, to routepackets, e.g., IP traffic, between a particular gateway in core network504 and UE 514. A bearer refers generally to an IP packet flow with adefined QoS between the particular gateway and UE 514. Access network502, e.g., E UTRAN, and core network 504 together set up and releasebearers as required by the various applications. Bearers can beclassified in at least two different categories: (i) minimum guaranteedbit rate bearers, e.g., for applications, such as VoIP; and (ii)non-guaranteed bit rate bearers that do not require guarantee bit rate,e.g., for applications, such as web browsing.

In one embodiment, the core network 504 includes various networkentities, such as MME 518, SGW 520, Home Subscriber Server (HSS) 522,Policy and Charging Rules Function (PCRF) 524 and PGW 526. In oneembodiment, MME 518 comprises a control node performing a controlsignaling between various equipment and devices in access network 502and core network 504. The protocols running between UE 514 and corenetwork 504 are generally known as Non-Access Stratum (NAS) protocols.

For illustration purposes only, the terms MME 518, SGW 520, HSS 522 andPGW 526, and so on, can be server devices, but may be referred to in thesubject disclosure without the word “server.” It is also understood thatany form of such servers can operate in a device, system, component, orother form of centralized or distributed hardware and software. It isfurther noted that these terms and other terms such as bearer pathsand/or interfaces are terms that can include features, methodologies,and/or fields that may be described in whole or in part by standardsbodies such as the 3GPP. It is further noted that some or allembodiments of the subject disclosure may in whole or in part modify,supplement, or otherwise supersede final or proposed standards publishedand promulgated by 3GPP.

According to traditional implementations of LTE-EPS architectures, SGW520 routes and forwards all user data packets. SGW 520 also acts as amobility anchor for user plane operation during handovers between basestations, e.g., during a handover from first eNB 516 a to second eNB 516b as may be the result of UE 514 moving from one area of coverage, e.g.,cell, to another. SGW 520 can also terminate a downlink data path, e.g.,from external network 506 to UE 514 in an idle state, and trigger apaging operation when downlink data arrives for UE 514. SGW 520 can alsobe configured to manage and store a context for UE 514, e.g., includingone or more of parameters of the IP bearer service and network internalrouting information. In addition, SGW 520 can perform administrativefunctions, e.g., in a visited network, such as collecting informationfor charging (e.g., the volume of data sent to or received from theuser), and/or replicate user traffic, e.g., to support a lawfulinterception. SGW 520 also serves as the mobility anchor forinterworking with other 3GPP technologies such as universal mobiletelecommunication system (UMTS).

At any given time, UE 514 is generally in one of three different states:detached, idle, or active. The detached state is typically a transitorystate in which UE 514 is powered on but is engaged in a process ofsearching and registering with network 502. In the active state, UE 514is registered with access network 502 and has established a wirelessconnection, e.g., radio resource control (RRC) connection, with eNB 516.Whether UE 514 is in an active state can depend on the state of a packetdata session, and whether there is an active packet data session. In theidle state, UE 514 is generally in a power conservation state in whichUE 514 typically does not communicate packets. When UE 514 is idle, SGW520 can terminate a downlink data path, e.g., from one peer entity 506,and triggers paging of UE 514 when data arrives for UE 514. If UE 514responds to the page, SGW 520 can forward the IP packet to eNB 516 a.

HSS 522 can manage subscription-related information for a user of UE514. For example, HSS 522 can store information such as authorization ofthe user, security requirements for the user, quality of service (QoS)requirements for the user, etc. HSS 522 can also hold information aboutexternal networks 506 to which the user can connect, e.g., in the formof an APN of external networks 506. For example, MME 518 can communicatewith HSS 522 to determine if UE 514 is authorized to establish a call,e.g., a voice over IP (VoIP) call before the call is established.

PCRF 524 can perform QoS management functions and policy control. PCRF524 is responsible for policy control decision-making, as well as forcontrolling the flow-based charging functionalities in a policy controlenforcement function (PCEF), which resides in PGW 526. PCRF 524 providesthe QoS authorization, e.g., QoS class identifier and bit rates thatdecide how a certain data flow will be treated in the PCEF and ensuresthat this is in accordance with the user's subscription profile.

PGW 526 can provide connectivity between the UE 514 and one or more ofthe external networks 506. In illustrative network architecture 500, PGW526 can be responsible for IP address allocation for UE 514, as well asone or more of QoS enforcement and flow-based charging, e.g., accordingto rules from the PCRF 524. PGW 526 is also typically responsible forfiltering downlink user IP packets into the different QoS-based bearers.In at least some embodiments, such filtering can be performed based ontraffic flow templates. PGW 526 can also perform QoS enforcement, e.g.,for guaranteed bit rate bearers. PGW 526 also serves as a mobilityanchor for interworking with non-3GPP technologies such as CDMA2000.

Within access network 502 and core network 504 there may be variousbearer paths/interfaces, e.g., represented by solid lines 528 and 530.Some of the bearer paths can be referred to by a specific label. Forexample, solid line 528 can be considered an S1-U bearer and solid line532 can be considered an S5/S8 bearer according to LTE-EPS architecturestandards. Without limitation, reference to various interfaces, such asS1, X2, S5, S8, S11 refer to EPS interfaces. In some instances, suchinterface designations are combined with a suffix, e.g., a “U” or a “C”to signify whether the interface relates to a “User plane” or a “Controlplane.” In addition, the core network 504 can include various signalingbearer paths/interfaces, e.g., control plane paths/interfacesrepresented by dashed lines 530, 534, 536, and 538. Some of thesignaling bearer paths may be referred to by a specific label. Forexample, dashed line 530 can be considered as an S1-MME signalingbearer, dashed line 534 can be considered as an S11 signaling bearer anddashed line 536 can be considered as an S6a signaling bearer, e.g.,according to LTE-EPS architecture standards. The above bearer paths andsignaling bearer paths are only illustrated as examples and it should benoted that additional bearer paths and signaling bearer paths may existthat are not illustrated.

Also shown is a novel user plane path/interface, referred to as theS1-U+ interface 566. In the illustrative example, the S1-U+ user planeinterface extends between the eNB 516 a and PGW 526. Notably, S1-U+path/interface does not include SGW 520, a node that is otherwiseinstrumental in configuring and/or managing packet forwarding betweeneNB 516 a and one or more external networks 506 by way of PGW 526. Asdisclosed herein, the S1-U+ path/interface facilitates autonomouslearning of peer transport layer addresses by one or more of the networknodes to facilitate a self-configuring of the packet forwarding path. Inparticular, such self-configuring can be accomplished during handoversin most scenarios so as to reduce any extra signaling load on the S/PGWs520, 526 due to excessive handover events.

In some embodiments, PGW 526 is coupled to storage device 540, shown inphantom. Storage device 540 can be integral to one of the network nodes,such as PGW 526, for example, in the form of internal memory and/or diskdrive. It is understood that storage device 540 can include registerssuitable for storing address values. Alternatively or in addition,storage device 540 can be separate from PGW 526, for example, as anexternal hard drive, a flash drive, and/or network storage.

Storage device 540 selectively stores one or more values relevant to theforwarding of packet data. For example, storage device 540 can storeidentities and/or addresses of network entities, such as any of networknodes 518, 520, 522, 524, and 526, eNBs 516 and/or UE 514. In theillustrative example, storage device 540 includes a first storagelocation 542 and a second storage location 544. First storage location542 can be dedicated to storing a Currently Used Downlink address value542. Likewise, second storage location 544 can be dedicated to storing aDefault Downlink Forwarding address value 544. PGW 526 can read and/orwrite values into either of storage locations 542, 544, for example,managing Currently Used Downlink Forwarding address value 452 andDefault Downlink Forwarding address value 544 as disclosed herein.

In some embodiments, the Default Downlink Forwarding address for eachEPS bearer is the SGW S5-U address for each EPS Bearer. The CurrentlyUsed Downlink Forwarding address” for each EPS bearer in PGW 526 can beset every time when PGW 526 receives an uplink packet, e.g., a GTP-Uuplink packet, with a new source address for a corresponding EPS bearer.When UE 514 is in an idle state, the “Current Used Downlink Forwardingaddress” field for each EPS bearer of UE 514 can be set to a “null” orother suitable value.

In some embodiments, the Default Downlink Forwarding address is onlyupdated when PGW 526 receives a new SGW S5-U address in a predeterminedmessage or messages. For example, the Default Downlink Forwardingaddress is only updated when PGW 526 receives one of a Create SessionRequest, Modify Bearer Request and Create Bearer Response messages fromSGW 520.

As values 542, 544 can be maintained and otherwise manipulated on a perbearer basis, it is understood that the storage locations can take theform of tables, spreadsheets, lists, and/or other data structuresgenerally well understood and suitable for maintaining and/or otherwisemanipulate forwarding addresses on a per bearer basis.

It should be noted that access network 502 and core network 504 areillustrated in a simplified block diagram in FIG. 5. In other words,either or both of access network 502 and the core network 504 caninclude additional network elements that are not shown, such as variousrouters, switches and controllers. In addition, although FIG. 5illustrates only a single one of each of the various network elements,it should be noted that access network 502 and core network 504 caninclude any number of the various network elements. For example, corenetwork 504 can include a pool (i.e., more than one) of MMEs 518, SGWs520 or PGWs 526.

In the illustrative example, data traversing a network path between UE514, eNB 516 a, SGW 520, PGW 526 and external network 506 may beconsidered to constitute data transferred according to an end-to-end IPservice. However, for the present disclosure, to properly performestablishment management in LTE-EPS network architecture 500, the corenetwork, data bearer portion of the end-to-end IP service is analyzed.

An establishment may be defined herein as a connection set up requestbetween any two elements within LTE-EPS network architecture 500. Theconnection set up request may be for user data or for signaling. Afailed establishment may be defined as a connection set up request thatwas unsuccessful. A successful establishment may be defined as aconnection set up request that was successful.

In one embodiment, a data bearer portion comprises a first portion(e.g., a data radio bearer 546) between UE 514 and eNB 516 a, a secondportion (e.g., an S1 data bearer 528) between eNB 516 a and SGW 520, anda third portion (e.g., an S5/S8 bearer 532) between SGW 520 and PGW 526.Various signaling bearer portions are also illustrated in FIG. 5. Forexample, a first signaling portion (e.g., a signaling radio bearer 548)between UE 514 and eNB 516 a, and a second signaling portion (e.g., S1signaling bearer 530) between eNB 516 a and MME 518.

In at least some embodiments, the data bearer can include tunneling,e.g., IP tunneling, by which data packets can be forwarded in anencapsulated manner, between tunnel endpoints. Tunnels, or tunnelconnections can be identified in one or more nodes of a network, e.g.,by one or more of tunnel endpoint identifiers, an IP address and a userdatagram protocol port number. Within a particular tunnel connection,payloads, e.g., packet data, which may or may not include protocolrelated information, are forwarded between tunnel endpoints.

An example of first tunnel solution 550 includes a first tunnel 552 abetween two tunnel endpoints 554 a and 556 a, and a second tunnel 552 bbetween two tunnel endpoints 554 b and 556 b. In the illustrativeexample, first tunnel 552 a is established between eNB 516 a and SGW520. Accordingly, first tunnel 552 a includes a first tunnel endpoint554 a corresponding to an S1-U address of eNB 516 a (referred to hereinas the eNB S1-U address), and second tunnel endpoint 556 a correspondingto an S1-U address of SGW 520 (referred to herein as the SGW S1-Uaddress). Likewise, second tunnel 552 b includes first tunnel endpoint554 b corresponding to an S5-U address of SGW 520 (referred to herein asthe SGW S5-U address), and second tunnel endpoint 556 b corresponding toan S5-U address of PGW 526 (referred to herein as the PGW S5-U address).

In at least some embodiments, first tunnel solution 550 is referred toas a two-tunnel solution, e.g., according to the GPRS Tunneling ProtocolUser Plane (GTPv1-U based), as described in 3GPP specification TS29.281, incorporated herein in its entirety. It is understood that oneor more tunnels are permitted between each set of tunnel end points. Forexample, each subscriber can have one or more tunnels, e.g., one foreach PDP context that they have active, as well as possibly havingseparate tunnels for specific connections with different quality ofservice requirements, and so on.

An example of second tunnel solution 558 includes a single or directtunnel 560 between tunnel endpoints 562 and 564. In the illustrativeexample, direct tunnel 560 is established between eNB 516 a and PGW 526,without subjecting packet transfers to processing related to SGW 520.Accordingly, direct tunnel 560 includes first tunnel endpoint 562corresponding to the eNB S1-U address, and second tunnel endpoint 564corresponding to the PGW S5-U address. Packet data received at eitherend can be encapsulated into a payload and directed to the correspondingaddress of the other end of the tunnel. Such direct tunneling avoidsprocessing, e.g., by SGW 520 that would otherwise relay packets betweenthe same two endpoints, e.g., according to a protocol, such as the GTP-Uprotocol.

In some scenarios, direct tunneling solution 558 can forward user planedata packets between eNB 516 a and PGW 526, by way of SGW 520. That is,SGW 520 can serve a relay function, by relaying packets between twotunnel endpoints 516 a, 526. In other scenarios, direct tunnelingsolution 558 can forward user data packets between eNB 516 a and PGW526, by way of the S1 U+ interface, thereby bypassing SGW 520.

Generally, UE 514 can have one or more bearers at any one time. Thenumber and types of bearers can depend on applications, defaultrequirements, and so on. It is understood that the techniques disclosedherein, including the configuration, management and use of varioustunnel solutions 550, 558, can be applied to the bearers on anindividual basis. That is, if user data packets of one bearer, say abearer associated with a VoIP service of UE 514, then the forwarding ofall packets of that bearer are handled in a similar manner. Continuingwith this example, the same UE 514 can have another bearer associatedwith it through the same eNB 516 a. This other bearer, for example, canbe associated with a relatively low rate data session forwarding userdata packets through core network 504 simultaneously with the firstbearer. Likewise, the user data packets of the other bearer are alsohandled in a similar manner, without necessarily following a forwardingpath or solution of the first bearer. Thus, one of the bearers may beforwarded through direct tunnel 558; whereas, another one of the bearersmay be forwarded through a two-tunnel solution 550.

FIG. 6 depicts an example diagrammatic representation of a machine inthe form of a computer system 600 within which a set of instructions,when executed, may cause the machine to perform any one or more of themethods described above. One or more instances of the machine canoperate, for example, as processor 302, UE 414, eNB 416, MME 418, SGW420, HSS 422, PCRF 424, PGW 426 and other devices described herein. Insome embodiments, the machine may be connected (e.g., using a network602) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client user machine in aserver-client user network environment, or as a peer machine in apeer-to-peer (or distributed) network environment.

The machine may comprise a server computer, a client user computer, apersonal computer (PC), a tablet, a smart phone, a laptop computer, adesktop computer, a control system, a network router, switch or bridge,or any machine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. It will beunderstood that a communication device of the subject disclosureincludes broadly any electronic device that provides voice, video ordata communication. Further, while a single machine is illustrated, theterm “machine” shall also be taken to include any collection of machinesthat individually or jointly execute a set (or multiple sets) ofinstructions to perform any one or more of the methods discussed herein.

Computer system 600 may include a processor (or controller) 604 (e.g., acentral processing unit (CPU)), a graphics processing unit (GPU, orboth), a main memory 606 and a static memory 608, which communicate witheach other via a bus 610. The computer system 600 may further include adisplay unit 612 (e.g., a liquid crystal display (LCD), a flat panel, ora solid-state display). Computer system 600 may include an input device614 (e.g., a keyboard), a cursor control device 616 (e.g., a mouse), adisk drive unit 618, a signal generation device 620 (e.g., a speaker orremote control) and a network interface device 622. In distributedenvironments, the embodiments described in the subject disclosure can beadapted to utilize multiple display units 612 controlled by two or morecomputer systems 600. In this configuration, presentations described bythe subject disclosure may in part be shown in a first of display units612, while the remaining portion is presented in a second of displayunits 612.

The disk drive unit 618 may include a tangible computer-readable storagemedium 624 on which is stored one or more sets of instructions (e.g.,software 626) embodying any one or more of the methods or functionsdescribed herein, including those methods illustrated above.Instructions 626 may also reside, completely or at least partially,within main memory 606, static memory 608, or within processor 604during execution thereof by the computer system 600. Main memory 606 andprocessor 604 also may constitute tangible computer-readable storagemedia.

FIG. 7 is an example system 700 including RAN 754 and core network 756.As noted above, RAN 754 may employ an E-UTRA radio technology tocommunicate with WTRUs 752 over air interface 764. RAN 754 may also bein communication with core network 756.

RAN 754 may include any number of eNode-Bs 702 while remainingconsistent with the disclosed technology. One or more eNode-Bs 702 mayinclude one or more transceivers for communicating with the WTRUs 752over air interface 764. Optionally, eNode-Bs 702 may implement MIMOtechnology. Thus, one of eNode-Bs 702, for example, may use multipleantennas to transmit wireless signals to, or receive wireless signalsfrom, one of WTRUs 752.

Each of eNode-Bs 702 may be associated with a particular cell (notshown) and may be configured to handle radio resource managementdecisions, handover decisions, scheduling of users in the uplink ordownlink, or the like. As shown in FIG. 7 eNode-Bs 702 may communicatewith one another over an X2 interface.

Core network 756 shown in FIG. 7 may include a mobility managementgateway or entity (MME) 704, a serving gateway 706, or a packet datanetwork (PDN) gateway 708. While each of the foregoing elements aredepicted as part of core network 756, it will be appreciated that anyone of these elements may be owned or operated by an entity other thanthe core network operator.

MME 704 may be connected to each of eNode-Bs 702 in RAN 754 via an S1interface and may serve as a control node. For example, MME 704 may beresponsible for authenticating users of WTRUs 752, bearer activation ordeactivation, selecting a particular serving gateway during an initialattach of WTRUs 752, or the like. MME 704 may also provide a controlplane function for switching between RAN 754 and other RANs (not shown)that employ other radio technologies, such as GSM or WCDMA.

Serving gateway 706 may be connected to each of eNode-Bs 702 in RAN 754via the S1 interface. Serving gateway 706 may generally route or forwarduser data packets to or from the WTRUs 752. Serving gateway 706 may alsoperform other functions, such as anchoring user planes duringinter-eNode B handovers, triggering paging when downlink data isavailable for WTRUs 752, managing or storing contexts of WTRUs 752, orthe like.

Serving gateway 706 may also be connected to PDN gateway 708, which mayprovide WTRUs 752 with access to packet-switched networks, such asInternet 760, to facilitate communications between WTRUs 752 andIP-enabled devices.

Core network 756 may facilitate communications with other networks. Forexample, core network 756 may provide WTRUs 752 with access tocircuit-switched networks, such as PSTN 758, such as through IMS core764, to facilitate communications between WTRUs 752 and traditionalland-line communications devices. In addition, core network 756 mayprovide the WTRUs 752 with access to other networks 762, which mayinclude other wired or wireless networks that are owned or operated byother service providers.

FIG. 8 illustrates an architecture of a typical GPRS network 800 asdescribed herein. The architecture depicted in FIG. 8 may be segmentedinto four groups: users 802, RAN 804, core network 806, and interconnectnetwork 808. Users 802 comprise a plurality of end users, who each mayuse one or more devices 810. Note that device 810 is referred to as amobile subscriber (MS) in the description of network shown in FIG. 8. Inan example, device 810 comprises a communications device (e.g., a mobiledevice, a mobile positioning center, a network device, a detected deviceor the like, or any combination thereof). Radio access network 804comprises a plurality of BSSs such as BSS 812, which includes a BTS 814and a BSC 816. Core network 806 may include a host of various networkelements. As illustrated in FIG. 8, core network 806 may comprise MSC818, service control point (SCP) 820, gateway MSC (GMSC) 822, SGSN 824,home location register (HLR) 826, authentication center (AuC) 828,domain name system (DNS) server 830, and GGSN 832. Interconnect network808 may also comprise a host of various networks or other networkelements. As illustrated in FIG. 8, interconnect network 808 comprises aPSTN 834, an FES/Internet 836, a firewall 1038, or a corporate network840.

An MSC can be connected to a large number of BSCs. At MSC 818, forinstance, depending on the type of traffic, the traffic may be separatedin that voice may be sent to PSTN 834 through GMSC 822, or data may besent to SGSN 824, which then sends the data traffic to GGSN 832 forfurther forwarding.

When MSC 818 receives call traffic, for example, from BSC 816, it sendsa query to a database hosted by SCP 820, which processes the request andissues a response to MSC 818 so that it may continue call processing asappropriate.

HLR 826 is a centralized database for users to register to the GPRSnetwork. HLR 826 stores static information about the subscribers such asthe International Mobile Subscriber Identity (IMSI), subscribedservices, or a key for authenticating the subscriber. HLR 826 alsostores dynamic subscriber information such as the current location ofthe MS. Associated with HLR 826 is AuC 828, which is a database thatcontains the algorithms for authenticating subscribers and includes theassociated keys for encryption to safeguard the user input forauthentication.

In the following, depending on context, “mobile subscriber” or “MS”sometimes refers to the end user and sometimes to the actual portabledevice, such as a mobile device, used by an end user of the mobilecellular service. When a mobile subscriber turns on his or her mobiledevice, the mobile device goes through an attach process by which themobile device attaches to an SGSN of the GPRS network. In FIG. 8, whenMS 810 initiates the attach process by turning on the networkcapabilities of the mobile device, an attach request is sent by MS 810to SGSN 824. The SGSN 824 queries another SGSN, to which MS 810 wasattached before, for the identity of MS 810. Upon receiving the identityof MS 810 from the other SGSN, SGSN 824 requests more information fromMS 810. This information is used to authenticate MS 810 together withthe information provided by HLR 826. Once verified, SGSN 824 sends alocation update to HLR 826 indicating the change of location to a newSGSN, in this case SGSN 824. HLR 826 notifies the old SGSN, to which MS810 was attached before, to cancel the location process for MS 810. HLR826 then notifies SGSN 824 that the location update has been performed.At this time, SGSN 824 sends an Attach Accept message to MS 810, whichin turn sends an Attach Complete message to SGSN 824.

Next, MS 810 establishes a user session with the destination network,corporate network 840, by going through a Packet Data Protocol (PDP)activation process. Briefly, in the process, MS 810 requests access tothe Access Point Name (APN), for example, UPS.com, and SGSN 824 receivesthe activation request from MS 810. SGSN 824 then initiates a DNS queryto learn which GGSN 832 has access to the UPS.com APN. The DNS query issent to a DNS server within core network 806, such as DNS server 830,which is provisioned to map to one or more GGSNs in core network 806.Based on the APN, the mapped GGSN 832 can access requested corporatenetwork 840. SGSN 824 then sends to GGSN 832 a Create PDP ContextRequest message that contains necessary information. GGSN 832 sends aCreate PDP Context Response message to SGSN 824, which then sends anActivate PDP Context Accept message to MS 810.

Once activated, data packets of the call made by MS 810 can then gothrough RAN 804, core network 806, and interconnect network 808, in aparticular FES/Internet 836 (and in embodiments a firewall), to reachcorporate network 840.

FIG. 9 illustrates a PLMN block diagram view of an example architecturethat may be replaced by a telecommunications system. In FIG. 9, solidlines may represent user traffic signals, and dashed lines may representsupport signaling. MS 902 is the physical equipment used by the PLMNsubscriber. For example, a network device, another electronic device,the like, or any combination thereof may serve as MS 902. MS 902 may beone of, but not limited to, a cellular telephone, a cellular telephonein combination with another electronic device or any other wirelessmobile communication device.

MS 902 may communicate wirelessly with BSS 904. BSS 904 contains BSC 906and a BTS 908. BSS 904 may include a single BSC 906/BTS 908 pair (basestation) or a system of BSC/BTS pairs that are part of a larger network.BSS 904 is responsible for communicating with MS 902 and may support oneor more cells. BSS 904 is responsible for handling cellular traffic andsignaling between MS 902 and a core network 910. Typically, BSS 904performs functions that include, but are not limited to, digitalconversion of speech channels, allocation of channels to mobile devices,paging, or transmission/reception of cellular signals.

Additionally, MS 902 may communicate wirelessly with RNS 912. RNS 912contains a Radio Network Controller (RNC) 914 and one or more Nodes B916. RNS 912 may support one or more cells. RNS 912 may also include oneor more RNC 914/Node B 916 pairs or alternatively a single RNC 914 maymanage multiple Nodes B 916. RNS 912 is responsible for communicatingwith MS 902 in its geographically defined area. RNC 914 is responsiblefor controlling Nodes B 916 that are connected to it and is a controlelement in a UMTS radio access network. RNC 914 performs functions suchas, but not limited to, load control, packet scheduling, handovercontrol, security functions, or controlling MS 902 access to corenetwork 910.

An E-UTRA Network (E-UTRAN) 918 is a RAN that provides wireless datacommunications for MS 902 and UE 924. E-UTRAN 918 provides higher datarates than traditional UMTS. It is part of the LTE upgrade for mobilenetworks, and later releases meet the requirements of the InternationalMobile Telecommunications (IMT) Advanced and are commonly known as a 4Gnetworks. E-UTRAN 918 may include of series of logical networkcomponents such as E-UTRAN Node B (eNB) 920 and E-UTRAN Node B (eNB)922. E-UTRAN 918 may contain one or more eNBs. User equipment (UE) 924may be any mobile device capable of connecting to E-UTRAN 918 including,but not limited to, a personal computer, laptop, mobile device, wirelessrouter, or other device capable of wireless connectivity to E-UTRAN 918.The improved performance of the E-UTRAN 918 relative to a typical UMTSnetwork allows for increased bandwidth, spectral efficiency, andfunctionality including, but not limited to, voice, high-speedapplications, large data transfer or IPTV, while still allowing for fullmobility.

Typically, MS 902 may communicate with any or all of BSS 904, RNS 912,or E-UTRAN 918. In a illustrative system, each of BSS 904, RNS 912, andE-UTRAN 918 may provide MS 902 with access to core network 910. Corenetwork 910 may include of a series of devices that route data andcommunications between end users. Core network 910 may provide networkservice functions to users in the circuit switched (CS) domain or thepacket switched (PS) domain. The CS domain refers to connections inwhich dedicated network resources are allocated at the time ofconnection establishment and then released when the connection isterminated. The PS domain refers to communications and data transfersthat make use of autonomous groupings of bits called packets. Eachpacket may be routed, manipulated, processed or handled independently ofall other packets in the PS domain and does not require dedicatednetwork resources.

The circuit-switched MGW function (CS-MGW) 926 is part of core network910, and interacts with VLR/MSC server 928 and GMSC server 930 in orderto facilitate core network 910 resource control in the CS domain.Functions of CS-MGW 926 include, but are not limited to, mediaconversion, bearer control, payload processing or other mobile networkprocessing such as handover or anchoring. CS-MGW 926 may receiveconnections to MS 902 through BSS 904 or RNS 912.

SGSN 932 stores subscriber data regarding MS 902 in order to facilitatenetwork functionality. SGSN 932 may store subscription information suchas, but not limited to, the IMSI, temporary identities, or PDPaddresses. SGSN 932 may also store location information such as, but notlimited to, GGSN address for each GGSN 934 where an active PDP exists.GGSN 934 may implement a location register function to store subscriberdata it receives from SGSN 932 such as subscription or locationinformation.

Serving gateway (S-GW) 936 is an interface which provides connectivitybetween E-UTRAN 918 and core network 910. Functions of S-GW 936 include,but are not limited to, packet routing, packet forwarding, transportlevel packet processing, or user plane mobility anchoring forinter-network mobility. PCRF 938 uses information gathered from P-GW936, as well as other sources, to make applicable policy and chargingdecisions related to data flows, network resources or other networkadministration functions. PDN gateway (PDN-GW) 940 may provideuser-to-services connectivity functionality including, but not limitedto, GPRS/EPC network anchoring, bearer session anchoring and control, orIP address allocation for PS domain connections.

HSS 942 is a database for user information and stores subscription dataregarding MS 902 or UE 924 for handling calls or data sessions. Networksmay contain one HSS 942 or more if additional resources are required.Example data stored by HSS 942 include, but is not limited to, useridentification, numbering or addressing information, ecurityinformation, or location information. HSS 942 may also provide call orsession establishment procedures in both the PS and CS domains.

VLR/MSC Server 928 provides user location functionality. When MS 902enters a new network location, it begins a registration procedure. A MSCserver for that location transfers the location information to the VLRfor the area. A VLR and MSC server may be located in the same computingenvironment, as is shown by VLR/MSC server 928, or alternatively may belocated in separate computing environments. A VLR may contain, but isnot limited to, user information such as the IMSI, the Temporary MobileStation Identity (TMSI), the Local Mobile Station Identity (LMSI), thelast known location of the mobile station, or the SGSN where the mobilestation was previously registered. The MSC server may containinformation such as, but not limited to, procedures for MS 902registration or procedures for handover of MS 902 to a different sectionof core network 910. GMSC server 930 may serve as a connection toalternate GMSC servers for other MSs in larger networks.

EIR 944 is a logical element which may store the IMEI for MS 902. Userequipment may be classified as either “white listed” or “black listed”depending on its status in the network. If MS 902 is stolen and put touse by an unauthorized user, it may be registered as “black listed” inEIR 944, preventing its use on the network. A MME 946 is a control nodewhich may track MS 902 or UE 924 if the devices are idle. Additionalfunctionality may include the ability of MME 946 to contact idle MS 902or UE 924 if retransmission of a previous session is required.

MTC-IWF 998 is shown communicatively coupled to MME 946 and HSS/HLR 942.Other functionality may be included as described herein, and further,other communicative connections may exist between MTC-IWF 998 and otherelements. More generally, FIG. 9 and other network images herein are, attimes, provided for purposes of technical context and may includeaspects unnecessary for full functionality of systems and methodsdisclosed herein. For example, EIR 944 may, but need not, be excluded inembodiments of the arrangement shown in FIG. 9 in conjunction withtechniques disclosed.

As described herein, a telecommunications system wherein management andcontrol utilizing a software defined network (SDN) and a simple IP arebased, at least in part, on user equipment, may provide a wirelessmanagement and control framework that enables common wireless managementand control, such as mobility management, radio resource management,QoS, load balancing, etc., across many wireless technologies, e.g. LTE,Wi-Fi, and future 5G access technologies; decoupling the mobilitycontrol from data planes to let them evolve and scale independently;reducing network state maintained in the network based on user equipmenttypes to reduce network cost and allow massive scale; shortening cycletime and improving network upgradability; flexibility in creatingend-to-end services based on types of user equipment and applications,thus improve customer experience; or improving user equipment powerefficiency and battery life—especially for simple M2M devices—throughenhanced wireless management.

While examples of a telecommunications system in which emergency alertscan be processed and managed have been described in connection withvarious computing devices/processors, the underlying concepts may beapplied to any computing device, processor, or system capable offacilitating a telecommunications system. The various techniquesdescribed herein may be implemented in connection with hardware orsoftware or, where appropriate, with a combination of both. Thus, themethods and devices may take the form of program code (i.e.,instructions) embodied in concrete, tangible, storage media having aconcrete, tangible, physical structure. Examples of tangible storagemedia include floppy diskettes, CD-ROMs, DVDs, hard drives, or any othertangible machine-readable storage medium (computer-readable storagemedium). Thus, a computer-readable storage medium is not a signal. Acomputer-readable storage medium is not a transient signal. Further, acomputer-readable storage medium is not a propagating signal. Acomputer-readable storage medium as described herein is an article ofmanufacture. When the program code is loaded into and executed by amachine, such as a computer, the machine becomes an device fortelecommunications. In the case of program code execution onprogrammable computers, the computing device will generally include aprocessor, a storage medium readable by the processor (includingvolatile or nonvolatile memory or storage elements), at least one inputdevice, and at least one output device. The program(s) can beimplemented in assembly or machine language, if desired. The languagecan be a compiled or interpreted language, and may be combined withhardware implementations.

The methods and devices associated with a telecommunications system asdescribed herein also may be practiced via communications embodied inthe form of program code that is transmitted over some transmissionmedium, such as over electrical wiring or cabling, through fiber optics,or via any other form of transmission, wherein, when the program code isreceived and loaded into and executed by a machine, such as an EPROM, agate array, a programmable logic device (PLD), a client computer, or thelike, the machine becomes an device for implementing telecommunicationsas described herein. When implemented on a general-purpose processor,the program code combines with the processor to provide a unique devicethat operates to invoke the functionality of a telecommunicationssystem.

What is claimed is:
 1. An apparatus, comprising: a processor; and amemory coupled with the processor, the memory storing executableinstructions that when executed by the processor cause the processor toeffectuate operations comprising: receiving a route request; routing theroute request to a node using a mapping of subscription information;receiving an overload report for one or more interfaces; and in responseto receiving the overload report, re-routing a device trigger from afirst home subscriber server (HSS) to a second HSS.
 2. The apparatus ofclaim 1, the operations further comprising: monitoring the one or moreinterfaces during an overload; and prioritizing the one or moreinterfaces.
 3. The apparatus of claim 1, wherein the re-routing is basedon a round trip time (RTT) latency evaluation.
 4. The apparatus of claim1, the operations further comprising applying back-off algorithms basedon a priority associated with the route request.
 5. The apparatus ofclaim 1, wherein the overload report is generated in response to an HSSegress of the first HSS.
 6. The apparatus of claim 1, wherein theoverload report is generated in response to device triggering initiatedby a plurality of machine to machine (M2M) application server-servingcapability server (AS-SCS) pairs at a same time.
 7. The apparatus ofclaim 1, wherein the routing is a route from a first device to a seconddevice to deliver a short message service (SMS) message to the seconddevice, and wherein the first device is associated with a first carrierand the second device is associated with a second carrier.
 8. A methodcomprising: receiving, by a processor, a route request; routing, by theprocessor, the route request to a node using a mapping of subscriptioninformation; receiving, by the processor, an overload report for one ormore interfaces; and in response to receiving the overload report,re-routing, by the processor, a device trigger from a first homesubscriber server (HSS) to a second HSS.
 9. The method of claim 8further comprising: monitoring the one or more interfaces during anoverload; and prioritizing the one or more interfaces.
 10. The method ofclaim 8, wherein the re-routing is based on a round trip time (RTT)latency evaluation.
 11. The method of claim 8 further comprisingapplying back-off algorithms based on a priority associated with theroute request.
 12. The method of claim 8, wherein the overload report isgenerated in response to an HSS egress of the first HSS.
 13. The methodof claim 8, wherein the overload report is generated in response todevice triggering initiated by a plurality of machine to machine (M2M)application server-serving capability server (AS-SCS) pairs at a sametime.
 14. The method of claim 8, wherein the routing is a route from afirst device to a second device to deliver a short message service (SMS)message to the second device, and wherein the first device is associatedwith a first carrier and the second device is associated with a secondcarrier.
 15. A computer readable storage medium storing executableinstructions that when executed by a computing device cause saidcomputing device to effectuate operations comprising: receiving a routerequest; routing the route request to a node using a mapping ofsubscription information; receiving an overload report for one or moreinterfaces; and in response to receiving the overload report, re-routinga device trigger from a first home subscriber server (HSS) to a secondHSS.
 16. The computer readable storage medium of claim 15, theoperations further comprising: monitoring the one or more interfacesduring an overload; and prioritizing the one or more interfaces.
 17. Thecomputer readable storage medium of claim 15, wherein the re-routing isbased on a round trip time (RTT) latency evaluation.
 18. The computerreadable storage medium of claim 15, wherein the overload report isgenerated in response to an HSS egress of the first HSS.
 19. Thecomputer readable storage medium of claim 15, wherein the overloadreport is generated in response to device triggering initiated by aplurality of machine to machine (M2M) application server-servingcapability server (AS-SCS) pairs at a same time.
 20. The computerreadable storage medium of claim 15, wherein the routing is a route froma first device to a second device to deliver a short message service(SMS) message to the second device, and wherein the first device isassociated with a first carrier and the second device is associated witha second carrier.